Skip to main content

Full text of "Specification of Internetwork Transmission Control Protocol"

See other formats


.I 
IEN: .5.5 
Socliom 2.4.2.1 
SPECIFICATION 
TRANSMISSION 
OF INTERNETWORK 
CONTROL PROTOCOL 
TCP 
Version 4 
September 1978 
Jonathan B. Postel 
'_..__September 1978 ' 
"I'['brmalion Sciences Institute. 
Universily of Soulhcrn California 
4676 Admirally Way 
▀ Marina del Rey, California 90291 
(213) 822-1511 
UNIVER$]TY OF 50UTHťRN CRLIFORNIR 
------------------------------<page break>-----------------------------
SePtember ! 978. 
]EN:55 
Section: 2.4.2.1 
Replaces: IENs 44, 
Control Protocol 
▀Transmission 
Version 
1. INTRODUCTION 
The Transmission Control Protocol (TCP)i$ intended for use as a' highly reliable host-to-host 
protocol between hosts in packet-switched computer communication networks, and especially tn 
Interconnected systems of such networks. 
This document describes the functions to be performed by the lnternetwork Transmission 
Control Protocol (TCP), the program that implements it, and its interface to Programs or users 
Ihal require Ils services. : . 
J.]. Histor, y.. ;.:.. ... 
'l:here have been'lout"previous TCP specifications= The first [CDS74]'defined' version 1, of 
TCP. A second I [PGR76a] was written for the Defense Communications Agency in 
connection..with Ills AUTODIN II project. The third [Cerf77] defined version 2, for use tn 
Ihe ARPA Intern!work research projects. 'The. fourth [CP78] defined version 3, a 
''"' refinement of verb'ion 2. 
: The AUTODIN II version differed from the original version In the.fol10wlng ways: 
Specification oF a resynchronization mechanism 'was included, and' fields for security and 
priority, which were' known requirements of AUTODIN.II, were added. 
The first Internet version (version 2) differed from the original version tn the followin g ways: 
A diffcrent resynchronization procedure was Introducetit an "option" field was defined 
for the TCP header to accommodate nol only security and priority but other special 
features 'concerned with, for example, segment speech services, diagnostic timestamping, 
and so on, 
Vcrsion 2 eliminaled all error messages but for'RESET, and thus simplified the header 
format. There are still many local errors which can be reported to the user but none of 
Ihese need cross the network(s) between TCP's. 
Connection closing was slightly more elaborate In Version 2 than in version ! because▀ the 
------------------------------<page break>-----------------------------
TCP-4 
Introduction 
September 1978 
FIN signals had to be acknowledged. Furthermore, the INT and FIN facilities no longer 
caused flushing of the data slream, (A separate "flush"facility was. tested, but 
eliminaled In the end.) Dealing with flow-centrol windows that have gone to zero was a 
new feature of version 2; and, finally, the reassembly of fragments Into segments was 
▀ more carefully specified. 
In version 3 TCP further evolvgd. The primary changes from version 2 were as follows: 
The resynchronizalion mechanism was eliminated in' favor of a quiet period on 
inilialization of the TCP. 
Bufl'er management and letlers boundaries were more tightly Couplld associated by the 
coupling of the end of letter flag to a receive buffer size. 
The interrupt siF, nal was eliminated in fa,or of an uricertl pointer. " 
A further separation of the internet and TCP specific' information in the segment format 
was achieved. 
Version 4 TCP Specified here has the followihg changes: 
'""The TCP now expects 'to call on a lower level protocol module in the host for certain 
/ functions; in the F. eneral Internetwork case, TCP expects the lower level module to 
..' implement the ARPA Internetwork Prolocot [Poste178d] or something functionally 
equivalent. to it. 
Addressins, information necessary to reach a.specific'TCP implementation Is expected to 
be carried on the lower level protocol. 
Frac, mcntalion and reassembly have been eliminated from TCP and made the 
responsibility of the lower level protocol. ' ' -. 
,t.2. Scope 
-.;,r" 
THe TCP is inlended to provide a reliable processto~process interprocess communication 
service in a mulEnetwork environment. The TCP is intended to be a host-to-host protocol in 
common use in mulliple networks. 
1.3. Olher Documentalion 
For other documentation, see the items cited in the History Section (1,1) and the items 
listed in the Biblio§raphy. 
[Pace 2] Postel 
------------------------------<page break>-----------------------------
IEN: 53 
John Davidson reporled on B§Ns UNIX TCP. It is now running TCP 
2.5, and should be running IN-4, and TCP-4 by 1 Nov, really aiming 
for 1 Oct. 
BBN's EON work may use the DTI version of TCP which is in C. This 
project, led by Wingfield, expects to have a C version for EDN by 
1 Jan 79. This version will.not be the same as the one used for 
the ARPA Inlernet project. 
ii) MIT - Dave Reed 
Dave reported that a Multdcs mplementaton of TCP version 2.1 was 
nearly completed. and now wor .is in progress on version 4. User 
side is straightforward. but ti)ere are policy problems to install 
server. MIT is also trying to. get a UNIX TCP, an ITS TCP, and a 
TOPS 2040 TCP. On the LCS NET progress is being made. Ti)e 2rd 
interface has been ordered, and testing is now underway between 
two mchines. A key problem at MIT is a shortage of IMP ports; in 
fact, they currently have two more hosts than ports. 
iii ) XEROX-PARC - John Shoch 
John reported on PARCs experiment using the PRNET as transit net 
between two ETtlERNETs. PARC now has about 22-25 net's (lost track 
of numbers), PARC is also doing a packet speech experiment using 
BYTE STREAM connection - up to 500 KB - so unencoded speech is 
sent. 
iv) SRI - Jim Mathis 
Jim reported that he has not really done much about converting to 
the new version of TCP and IN. He is waiting to see if version 4 
turns into version 4.1) On the Port Expander idea things are 
progressing slowly also, the current thing works with the 32 bit 
1822 leaders. 
v) UCL - Andrew Hinchley 
Andrew reported that the FTP standard from the EPSS group will be 
brought up on a Tenex so that expermients with end;to-end FTP 
between EPSS hosts and an ARPANET host can be performed, and 
possible expermients with hosts in other in X.25 networks. 
f J otes 
Internet Meeting N 
Postel 
[page 
21 August lg78 
IEN: 53 
Internet Meeting Notes 
vii NDRE - Yngvar Lund 
Yngvar discussed the state of development at NDRE. A TCP-3 is 
near completion for the NORD-10 and is nearly ready for testing. 
The need for a TCP on ELF was pointed out. 
vii) CCA - Kou Mei Chuang 
Kou Mei reported on the progress at CCA. Currently they are 
converting a TCP-11 supplied by Jim Mathis to run under RSX-lt. 
This is version 2.5. When Jim can supply a version 4, they will 
cover that. 
It is clear that Jim Mathis is the leader on TCP-4 & IN-4 for 
pdp-11s. Everyone ti)at s ting for his program'to be available 
should contact him. 
viii) LL - Jim Forgie 
Jim Forgie remarked that speech conferenctng hnd been demonstrated 
in SATNET with SIMP-1. SIMP-3 is up now, 'al)d speech is unusable 
d,,o tn now dolny problems. There is a need to do internet speech 
------------------------------<page break>-----------------------------
-- Messages from file: [PARC-MAXC]<SIIDCII)MESSAGE.TXT;t 
-- TUESDAY, OCTDBER 10, 1978 20:53:27-PDT -- 
Date: g OCT 1978 lg51-PDT 
From: POSTEL at USC-ISIB 
Subject: TCP Meeting Notes 
To: [ISIE]<Postel>TCP-INTERNET.List: 
The following 26 pages are the meeting notes from the TCP meeting held at 
SRI 18 & 19 Septembgr. The notes are so long becausetey includ as a set 
o as the memos detailing the TCP implementation status distributed 
at the meeting. The notes are also in the file -- 
<INTERNET-NOTBOOK)TCP-MEETING-NOTES.TXT at ISIE. 
Jon Postel 
9 October lg78 
es - 18 
Editors Note 
This meeting was billed as a TCP testing session. The first hour or 
so of the meeting was taken up with a discussion of what the various 
implementors present expected their programs to be able to accomplish 
with the programs of the other implementors. 
It became apparent that almost no useful demonstrations could 6e 
performed due to the differences between the implementations'. 
The planned agenda was discarded, and the meeting turned primarily 
into a discussion of the specifications of TCP with a few remarks 
about testing procedures. 
Much of the detail of the discussion of the TCP specifications will 
be omitted from thpse notes, but the information will be conveyed to 
the specification editor for use in the next edition. 
Discussion of the State of TCP Implementations 
! 
The TCP implementations available for testing at the meeting 
SRI: TCP 2.5 
BBN Tenex/Tops 20: TCP 2.X 
UCLA: TCP 4 
BBN Unix: TCP 2.5 
MIT Multics: not ready 
The state of BBN's Tenex and Tops 20 versions was explored in some 
detail: 
Version Comments 
2.5-e 
Tested; BCPL, running at ISI; "old faithful"; has 
resynchronization ARQ, RSN, INT, etc. 
2.5 
Tested; BCPL & Monitor versions; running at SRI-KA; 
INT, RSN,ARQ removed, code cleaned up. 
2.5+e 
Tested; Hand coded; running at BBND, BBNC; bugs 
fixed, 
Postel 
[page 1] 
9 October 1978 
TCP Meeting Notes 
------------------------------<page break>-----------------------------
,-' e cotermJnou. the CCA revtston ot this software. 
-/ 
PARC - Shoch : .k. 
John brtefly revte.ed the status of networks at XEROX, There are 
7 types of nets, 20 nes, 500 hosts, The particular experiment of 
interest to the IN group is the use of the PRNET as a link between 
two ETIIERNETs located about a mile apart. Adding the Radionet to 
the existing Parc internetwork architecture required building an 
1822 interface, and adding a network-specific driver for the 
Radionet in the gateway at each end. This driver performs network 
specific fragmentation, splitting up large intOmet packets into 
smaller fragments that can be sent through the Radionet.'.,.,. 
Over 1000 hours of gateway operation have been accumulated, and 
the system seems to work well; the radio link can support one-way 
byte stream traffic at about 12 KS/S. John noted that measurement 
shows that they can get about 8.3 KS/S from a line rated at 9.6 
KS/S; and out or,the 100 KS/S radio channel, they can usually get 
12.5 KS/S; and if all the paramenters are tuned, they can on 
occasion get 25 to 30 KS/S. 
John also discussed a flow control problem that can seriously 
effect throughput. Basically, the variability in delay may 
trigger undesirable retransmissions that result in every message 
being sent twice. These effects may be repeated resulting in 
every message being sent many times. The serious part of the 
problem is that such States may be stable. This topic is further 
discussed later in the meeting. 
This particular failure mode has since been corrected, by slightly 
modifying the flow control heuristics, and system behaves 
properly. This experience again highlights the difficulty of 
designing good flow control and congestion control mechanisms, 
especially when inter-connecting networks whose basic performance 
differs by several orders of magnitudes. 
John also requested contributions to a bibliography on local 
networks that he is preparing. 
Postel 
Internet Meeting Notes 
IEN 76 
MITRE - Skelton 
Anita reported that the MITRE-Unix is now up. and the local 
network is installed with 6 interface units in place. The local 
net is based on cable TV technology using a 300 MB base band with 
a 200 KB subchannel for packet data transmission. TTY-to-TTY 
connections have..been testeU on the cable, and the 11/70 is being 
connected via a single DH-11 line with software multiplexing. 
Eventually, the 11/70 will interface to the cable via a UMC-Z80. 
There are three LSI-11s soon to be connected to the cable. These 
could run tl)e MOS-TCP from Jim Mathis. Anita will provide some 
material from a MITRE working paper for an IEN describing the 
network. 
FORD - Ken Biba 
Ken discuss6d the work at FORD on the KSOS (Kernelized Secure 
Operating System). This is to be a UNIX-like system with 
multi-level security. The Critical Design Review is at the end of 
February. The system will be written in MODULA (possible fall 
back is "C"), Ken pointed out the problem o handling IN protocol 
fragment reassembly in a secure system. This is further iscq.ssed 
in IEN-73. The key issue seems to be to provi some 
demultiplexing information in every fragment so as to not require 
"shared" storage in tho kornol, 
Ken also reported that FORD is building a local net based on an 
1MB channel with MA connections to PDP-11s. The network hosts 
will use NCPs. The network inturface is based on a UMC-ZO0 froin 
ACC, 
------------------------------<page break>-----------------------------
Vint Cerf 
DARP A / IP TO 
1 April 80 
FINAL REPORT OF %HE STkNFORD' 
UNIVERSITY TCP PROJECT 
.Vinton G. Cerf 
1 April 1980 
ABSTRACT: 
This report provides a brief historical and technical sunnary of the 
Stanford University internet, host-to-host Transmission Control Protocol 
(TCP) project. Developed from 1973-1976 at Stanford, Bolt Beranek and 
Newman and University College London, the effort then continued at other. 
r. esearch and development centers during 1977-1980. Originally designed 
s a monolithic internet protocol, the internet aspects were separated 
into a distinct protocol layer in early 1979 with the publication of 
_version 4 of TCP. The resulting pair of protocols, TCP4 and Internet 
Protocol (IP) are now undergoing procedures for standardization within 
the DoD and Intelligence Community. The four most valuable results of 
the Stanford effort were the assessment of which functions could or 
should be implemented in the protocol and which should not, the 
implementation of an efficient, assembly-language version of TCP for an 
LSI-11 computer, the development of a "micro" operating system (MOS) for 
the same computer, and the specificiation of the TCP protocol. 
1. Introduction: 
The Stanford TCP project was supported by 'h9 Defense Advanced Research 
Projects Agency (DARPA) under contract'No. DAHC 15-73-C-0363 and 
MDA903-76-C-0206, ARPA Order No. 2494 during the period 1 July 1973 to 
30 September 1976. During the time that the project was at Stanford, 
two versions of TCP were developed, one in December 1974 [1] and another 
which was ublished in March 1977 [2], by DARPA. Since that time, two 
other versions have been published, versions 3 and 4 [3,4] in January 
1978 and February 1979, respectively. Editing of these latter versions 
was the responsibility of J. Postel, Information Sciences Institute, 
University of Southern California. Intermediate versions were published 
in July 1976 [5], July 1978 [6], and August 1979 [7]. The July 76 
version was developed for the Defense Communication Agency by J. Postel, 
L. Garlick and R. Ram of Stanford Research Institute for the Defense 
Communication Agency in connection with the AUTODIN II project. The 
final verions of TCP and Internet Protocol were published in January, 
1980 [24,15] by DARPA on behalf of the Defense Communication Agency. 
------------------------------<page break>-----------------------------
During the course of' the DARPA Internetting program, which supported.the 
TCP development, a great many people and groups were involved in or 
influenced the development of the TCP. 
The initial impetus for the effor.t resufed from work by R. Kahn and V. 
Cerf, which was published in May 1974 [8], but whose basic roots were 
already known in September 1973 [9]. 
An initial design for TCP was worked out during 1973-74 at Stanford 
among V. Cerf, Y. Dalal, C. Sunshine and R. Karp, with the participation 
of R. Tomlinson [Bolt Beranek and Newman], W. Plumruer [BBN], R. Metcalfe 
[Xerox PARC] and D. Boggs [Xerox PARC]. Implementation, testing and 
further development were carried out jointly at Stanford with J. Mathis 
and J. Estrin, Bolt Beranek and Newman, and University College London 
[F. Deignan, C. J. Bennett, A. J. Hinchley and M. Galland]. Visiting at 
Stanford during this initial development period were G. LeLann 
[University of Rennes, France] and D. Belsnes [University of Oslo] who 
provided additional philosophical leavening which influenced the design 
of the protocol. 
By 1976, implementations had been written for the Tenex/PDP-10 
[Tomlinson, Pler- in BCPL], ELF/PDP-11 [Tomlinson, Plumruer- in 
BCPL; Karp, Dalal, Cerf - BCPL], LSI-11 [Math is - assembly language], 
PDP-9. [Deignan - BABBAGE] and some performance experience obtained [10]. 
Since then, implementations have been pursued for UNIX [M. Wingfield - 
"C"; J. Haverty- assembly language], OS 360 [B. Braden - assembly 
language], Multics [D. Clark - PL/1], TOPS-20 [W. Plummer - assembly 
language], and NORD-10 [A. Stensby]. 
2. TECHNICAL ISSUES 
The initial concept behind TCP was very simple. Two processes wishing 
to communicate had only to know the other's "address". Data would be 
accounted for in 8-bit octets, and sequence numbers would be used to 
re-order the received data.at the destination,:' if necessary. The first 
packet would have a special synchronization fl. ["SYN"] which would 
alert the receiver that the sender's sequence numbers would start with 
the one associated with the "SYN" packet. All control information would 
be associated with data sequence numbers so that end to end' 
acknowledgements for data could also be used to.acknowledge control. If 
resynchronization were needed, the sender could simply send another 
"SYN" packet. There would be no used for a "connection set-up" in the 
conventional sense. Finally, packet formats would permit internet 
gateways to fragment packets into identically formatted, smaller packets 
if necessary, to get through a net with a smaller packet size. 
Reassembly of fragments would be done by the destination. 
------------------------------<page break>-----------------------------
F 
a hazard if the host failed just as the "next sequence number" to use 
fell into the so-called initial sequence number "forbidden zone". A 
complex set of t.,ests were defined to catch this case, but required 
action on each packet transmitted to determine whether the hazardous 
"forbidden" zone had been entered. If so, the sequence numbers on the 
connection would be re-synchroniz to skip around the danger area. The 
probability of the hazard actually occuring was judged to be quite 
small, and finally these tests were eliminated, vastly simplifying the 
TCP definition and implementation. 
The third critical issue had to do with the treatment of packets which 
required fragmentation to pass through a network. Gateways between nets 
were postulated which could detedt that an incoming packet was too large 
to fit encapsulated in the packet format of the next network. 
A fragmentation strategy was developed which permitted an internet 
packet to be fragmented into smaller packets and marked in such a way 
that the resulting fragments could be routed independently of one aother 
and could still be reassembled at the final destination. 
A major change to the TCP philosophy occurred when the basic 
in. ternetting functions (addressing, fragmentation and type of service 
selection) were separated from the end to end functions of TCP ▀ 
(sequencing, retransmission, duplicate detection, flow control and pqrt 
multiplexing). At this point, the fragmentation problem was 
substantially simplified since it applied only to the internet packets 
and limited knowledge of protocols to the IP layer in the gateway. 
t the same time, this permitted other higher level protocols, adjacent 
o the TCP layer, to rely on the special services, including 
fragmentation and reassembly, of the IP protocol layer. 
Network Security 
The TCP concepts were applied to the ARPA network security program and 
an architecture was developed which accommodated the use of TCP as an 
end to end protocol, below which, end to end encryption could take 
place. This architecture became even simpler when the TCP was split. 
from the internet protocol functions since security was provided at the 
IP level, allowing many different transport protocols, in addition to 
TCP, to be secured by the same basic system. 
Implementation and Experimentation 
Two TCPs were developed during this project: 
1. BCPL for DP-11 under ELF operating system. 
------------------------------<page break>-----------------------------